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METHOD AND SYSTEM FOR COMMUNICATING WITH A VIRTUAL 

CIRCUIT NETWORK 



TECHNICAL FIELD 



This invention relates generally to computer networking and, more 



particularly, relates to a method and system for communicating with a virtual-circuit 
network. 



ordinary households and small businesses to obtain broadband access to powerful 
computer networks, such as the Intemet, over ordinary telephone company lines. The 
advent of new virtual-circuit protocols has made high speed voice and video 
communication over broadband networks efficient and practical. Virtual-Circuit 

15 protocols allow the definition of a specific data path through a network using an 

identifier known as a "virtual circuit." AVhile a datagram-based transport method such 
as an Litemet Protocol (IP) packet is permitted to travel through a variety of network 
links, virtual-circuit packets are forced to travel over their designated virtual circuits. 
One popular virtual-circuit protocol is the Asynchronous Transfer Mode (ATM) 

20 protocol. The growing use of ATM has made the transmission of real-time movies 
and voice over large networks such as the Litemet a reality. To enhance the consumer 
experience with ATM, the remote NETWORK DRIVER SPECIFICATION (NDIS) 
developed by MICROSOFT CORPORATION may include an ATM miniport which 
allows a personal computer to communicate with an ATM network. The remote 



BACKGROUND OF THE INVENTION 
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New technologies such as Digital Subscriber Line (DSL) have enabled 



# 
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NDIS is the subject of U.S. Patent Application No. 09/302,735 for a METHOD AND 
SYSTEM FOR ABSTRACTING NETWORK DEVICE DRIVERS, which is 
incorporated by reference herein in its entirety. 

With the increasing demand for access to virtual circuit networks, many 

5 households and businesses will experience intemal competition for the limited 
number of broadband data lines, and will therefore have to institute a system of 
connection sharing in order to take advantage of the new virtual-circuit-based 
protocols. Additionally, more and more ordinary devices, such as televisions and 
radios, are being adapted to use networks such as the Intemet, thereby increasing the 

10 competition for the use of these data lines. Thus, it can be seen that there is a need for 
an improved method and system for communicating with a virtual-circuit network. 



15 communicating with a virtual-circuit network is provided, in which one or more 
calling devices in an intemal network may communicate with a virtual-circuit 
network, such as an ATM network, via a proxy host. 

According to the method, a host computer communicatively linked with a 
virtual circuit network and communicatively linked with a device (which may be a 

20 personal computer) over a local area network receives a virtual circuit message from 
the virtual circuit network, such as an asynchronous transfer mode network. A data 
structure associating a virtual circuit of the virtual circuit network with the device is 
referenced, and based on the association, the virtual circuit message is passed to the 



SUMMARY OF THE INVENTION 



In accordance with this need, an improved method and system for 



device over the local area nelwork. The data structure may be a table containing an 
entry associating the virtual circuit with the device or with the network address of the 
device. 

The system may comprise a proxy host computer. The proxy host computer 
5 may execute several programs, including a networking program for unwrapping a 
device message received from the virtual circuit network to extract a virtual circuit 
message; a call deflector program for determining an association between a device on 
a local area network to which the proxy host is linked and a virtual circuit of the 
virtual circuit network; and a packet switching program for passing the extracted 
10 virtual circuit message to the device over the local area network based on the 

determined association. The networking program may be a network device interface 
specification layer having an asynchronous transfer mode miniport. 

The proxy host may also execute a bus driver for unwrapping a bus-specific 
message to extract a device message received from an interface device connected to 
15 the virtual circuit network. 

In addition to the proxy host, the system may further comprise a plurality of 
devices communicatively linked to the proxy host over the local area network, 
wherein each of the plurality of devices may execute the networking program to 
unwrap a virtual circuit message received from the proxy host to extract data and pass 
20 the data to an application program, wherein the application program provides the data 
to a user at the device. 



Additional features and advantages of the invention will be made apparent 
from the following detailed description of illustrative embodiments, which proceeds 
with reference to the accompanying figures. 

BRIEF DESCRIPTION OF THE DRAWINGS 

While the appended claims set forth the features of the present invention with 
particularity, the invention, together with its objects and advantages, may be best 
understood from the following detailed description taken in conjunction with the 
accompanying drawings of which: 

Figure 1 is a block diagram generally illustrating an exemplary computer 
system on which the present invention may reside; 

Fig. 2 is a block diagram illustrating an exemplary virtual circuit network over 
which a device may communicate in accordance with the invention; and 

Fig. 3 is a block diagram of a network of calling devices and a proxy host 
configured in accordance with the invention. 

DETAILED DESCRIPTION OF THE INVENTION 

Turning to the drawings, wherein like reference numerals refer to like 
elements, the invention is illustrated as being implemented in a suitable computing 
environment. Although not required, the invention will be described in the general 
context of computer-executable instructions, such as programs, being executed by a 
computer or similar device. Generally, programs include routines, other programs, 
objects, components, data structures, dynamic-linked libraries (DLLs), executable 



code, etc. that perform particular tasks or implement particular abstract data types. 
Moreover, those skilled in the art will appreciate that the term "computer" is not 
meant to limit the invention to personal computers, as the invention may be practiced 
on hand-held devices, multi-processor systems, microprocessor based or 
5 programmable consumer electronics, network devices, minicomputers, mainframe 
computers, and the like. The invention may also be practiced in distributed 
computing environments where tasks are performed by remote processing devices 
that are linked through a communications network. In a distributed computing 
environment, parts of a program may be located in both local and remote memory 

10 storage devices. 

With reference to Fig. 1 , an exemplary system for implementing the invention 
is shown. The system includes a general purpose computer in the form of a 
conventional computer 20, including a processing unit 21, a system memory 22, and a 
system bus 23 that couples various system components including the system memory 

15 to the processing unit 2 1 . The system bus 23 may be any of several types of bus 

structures including a memory bus or memory controller, a peripheral bus, and a local 
bus using any of a variety of bus architectures. The system memory may include read 
only memory (ROM) 24 and random access memory (RAM) 25. A basic input/output 
system (BIOS) 26, containing the basic routines that help to transfer information 

20 between elements within the computer 20, such as during start-up, may be stored in 
the ROM 24. The computer 20 may further include a hard disk drive 27 for reading 
from and writing to a hard disk 60, a magnetic disk drive 28 for reading from or 
writing to a removable magnetic disk 29, and an optical disk drive 30 for reading 



from or writing to a removable optical disk 3 1 such as a CD ROM or other optical 
media. 

If included in the computer 20, the hard disk drive 27, magnetic disk drive 28, 
and optical disk drive 30 may be connected to the system bus 23 by a hard disk drive 
5 interface 32, a magnetic disk drive interface 33, and an optical disk drive interface 34, 
respectively. The drives and their associated computer-readable media provide 
nonvolatile storage of computer readable instructions, data structures, programs and 
other data for the computer 20. Although the exemplary environment described 
herein employs a hard disk 60, a removable magnetic disk 29, and a removable optical 

10 disk 3 1, it v^ill be appreciated by those skilled in the art that other types of computer 
readable media v^hich can store data that is accessible by a computer, such as 
magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, 
random access memories, read only memories, and the like may also be used in the 
exemplary operating environment. 

15 A number of programs may be stored on the hard disk 60, magnetic disk 29, 

optical disk 31, ROM 24 or RAM 25, including an operating system 35, one or more 
apphcations programs 36, other programs 37, and program data 38. A user may enter 
commands and information into the computer 20 through input devices such as a 
keyboard 40, which is typically connected to the computer 20 via a keyboard 

20 controller 62, and a pointing device, such as a mouse 42. Other input devices (not 
shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the 
like. Input devices as well as peripheral devices may be connected to the processing 
unit 21 through a serial port interface 46 that is coupled to the system bus, a parallel 



port, game port, universal serial bus (USB), 1394 bus, or other interfaces. A monitor 
47 or other type of display device is also connected to the system bus 23 via an 
interface, such as a video adapter 48. In addition to the monitor, computers typically 
include other devices not shown, such as speakers and printers. 
5 The computer 20 may operate in a networked environment using logical 

connections to one or more devices within a network 63, including another personal 
computer, a server, a router, a network PC, a peer device or other common network 
node. These devices typically include many or all of the elements described above 
relative to the computer 20. The logical connections depicted in Figs, 1 and 2 include 

10 one or more network links 5 1 , for which there are many possible implementations, 
including a local area network (LAN) link and a wide area network (WAN) link. 
Such networking links are commonplace in offices, enterprise- wide computer 
networks, intranets and the Internet. It will be appreciated that the network 
connections shown are exemplary and other means of establishing a data path 

15 between the computers may be used. When used in a LAN, the computer 20 may be 
connected to the network 63 through a network interface or adapter 53. When used in 
a WAN, the computer 20 typically includes a modem 54 or other means for 
establishing communications over the network link 51, as shown by the dashed line in 
Fig. 1 . The network link 5 1 may also be created over public networks, using 

20 technologies such as dial-up networking, the Intemet, Digital Subscriber Line (DSL), 
Asynchronous Transfer Mode (ATM), Virtual Private Network (VPN) or any other 
conventional communication method. The modem 54 may be connected to the 
system bus 23 via the serial port interface 46, and may be extemal or intemal. In a 



networked environment, programs depicted relative to the computer 20, or portions 
thereof, may be stored on other devices within the network 63. 

hi the description that follows, the invention will be described with reference 
to acts and symbolic representations of operations that are performed by one or more 
5 computers, unless indicated otherwise. As such, it will be understood that such acts 
and operations, which are at times referred to as being executed, include the 
manipulation by the processing unit of the computer of electrical signals representing 
data in a structured form. This manipulation transforms the data or maintains it at 
locations in the memory system of the computer, which reconfigures or otherwise 

10 alters the operation of the computer in a manner well understood by those skilled in 
the art. The data structures where data is maintained are physical locations of the 
memory that have particular properties defined by the format of the data. However, 
while the invention is being described in the foregoing context, it is not meant to be 
limiting as those of skill in the art will appreciate that various of the acts and 

15 operation described hereinafter may also be implemented in hardware. 

The invention is generally directed to a method of communicating with a 
virtual circuit network, such as an ATM network 120 shown in Fig. 2. The ATM 
network 120 includes ATM switches 70-76 which are communicatively linked to one 
another by network links 122. Each switch 70-76 may include hardware and software 

20 for sending and receiving data. Each switch 70-76 has one or more ports, which may 
be logical or physical. Each port may have one or more virtual circuits associated 
with it. Each ATM cell has "virtual circuit" (VC) identifier to indicate the virtual 
circuit over which the cell is to travel. A VC is an abstract boundary between switch- 



based communication sessions, and as applied to ATM communication, generally 
represents the combination of an ATM "virtual path identifier" (VPI) and an ATM 
"virtual channel identifier" (VCI). Thus, an ATM message having a VPI of 3 and a 
VCI of 1 is said to be traveling "VC 3:1." 
5 One or more computers, such as the computers 100a and 100b, may be linked 

to the netv^ork 120 via ATM interface devices 124a and 124b. The ATM interface 
devices 124a and 124b convert ATM cells into a standard networking format, such as 
USB, and vice versa, using an ATM driver. When an ATM call is placed from an 
originating computer 100a to a receiving computer 100b via the network 120, an 

10 ATM Setup signal is transmitted from the originating computer 100a to the ATM 
interface device 124a, which then transmits the ATM Setup signal over a VC 
conventionally designated for signaling (typically VC 0:5). The ATM Setup signal is 
then relayed among the switches 70-74 along a data path 126 until it reaches the ATM 
interface device 124b, which translates the ATM Setup signal into a format 

15 understandable by the receiving computer 100b. To accept the call, the computer 
100b transmits an ATM Connect signal to the ATM interface device 124b, which 
transmits the ATM Connect signal back through the network 120 along the data path 
126. As the acceptance signal travels back to the computer 100a, each switch along 
the way processes the acceptance signal by allocating a new virtual circuit to be used 

20 for all further ATM communication between the device 100a and the device 100b 
along that segment of the data path 126. For example, the switch 74 may allocate VC 
0:35 for ATM communication between it and the device 100a and VC 0:34 for the 
ATM communication between it and the switch 72. Switch 72, in turn, may allocate 




VC 0:35 for the ATM communication between it and the switch 70. Finally, the 
switch 70 may allocate VC 0:33 for communication between it and the computer 
100b. 

To ensure that the communication between the device 100a and 100b travels 
5 over the correct VC's, each switch stores an entry that associates an input VC of an 
input port with an output VC on an output port. For example, it is assumed that the 
switch 74 of Fig. 2 has two ports: Port X, which is in communication with the device 
20b, and Port Y, which is in communication with the switch 72. The switch 74 will 
have a table entry that associates VC 0:35 of Port X with VC 0:34 of Port Y, thereby 

10 indicating to the switch 74 that all traffic received on VC 0:35 of Port X is to be 
switched to VC 0:34 on Port Y for output and vice versa. When the call has 
concluded, one or both of the computers 100a and 100b transmits a termination signal 
over the network 120 and the switches 70-76 respond by deallocating the previously 
allocated VCs and deleting the corresponding table entries. In the case of a so-called 

15 "Permanent Virtual Circuit" (PVC), the data path 126 is permanently defined within 
the switches 70 - 76, in which case the initial setup and final deallocation processes 
need not occur. 

In accordance with an embodiment of the invention shown in Fig. 3, calling 
devices 88a-88b, which may have many or all of the components of the computer 20 
20 described in Fig. 1 , are communicatively linked via network interface cards (NICs) 
99a and 99b respectively to a network link 98a. The network link 98a is further 
linked to a proxy host 82 via a network interface card 99c. Although only two calling 
devices are shown, any number of calling devices is possible. The network link 98a is 



11 



preferably a local area network link, such that the calling devices 88a-88b and the 
proxy host 82 comprise a local area network. 

The proxy host 82 is communicatively linked to a virtual circuit interface 
device 92 via a network interface card 99d and a network link 98b. The virtual circuit 

5 interface device 92 may be implemented as an ATM-compatible Digital Subscriber 
Line (DSL) interface, and may include an ATM adaptation layer five (AAL 5). The 
virtual circuit interface device 92 is communicatively linked a virtual circuit network 
96 via a network link 98c. The virtual circuit network 96 may be an ATM network 
such as the ATM network 120 of Fig. 3. To aid in a description below of how 

10 communication occurs across the network 96, it will be assumed that a receiving 

device 93a and a receiving device 93b are also communicatively liked to the network 



The calling devices 88a and 88b may each execute application programs 85a 
and 85b, which may receive input from or provide output to a user. The application 

15 programs 85a and 85b may include one or more protocol programs such as a TCP/IP 
stack, an IP Over ATM (IPOA) protocol program and a Point-to-Point Protocol Over 
ATM (PPPOA) protocol program. The calling devices 88a and 88b may also execute 
networking programs 81a and 81b, which convert data into a standard format, 
hereinafter referred to as a device message, that can be interpreted by networking 

20 devices. Conversely, the networking programs 81a and 81b extract data from device 
messages received from networking devices. The process of inserting data having 
one format into a message having another format will hereinafter be referred to as 
"wrapping" the data. Performing the process in reverse (i.e. extracting data of one 



96. 
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format from a message having another format) will hereinafter be referred to as 
"unwrapping" the data. These terms are also commonly used in conjunction with 
protocol layers, in which data may be wrapped into, for example, a transport layer, a 
networking layer, a data link layer and a physical layer. 
5 In a preferred embodiment of the invention, the networking programs 81a and 

81b are implemented as a NETWORK DRIVER INTERFACE SPECIFICATION 
(NDIS) abstraction layer having a User Network Interface (UNI) call manager and a 
remote NDIS ATM miniport. NDIS is a well-known standard defined by the 
MICROSOFT CORPORATION, which provides a universal set of OBJECT 

10 IDENTIFIERS (OIDs) which can be understood and used by any hardware device 
that is NDIS-compliant. An embodiment of NDIS having a remote NDIS extension is 
described in U.S. Patent Application no. 09/302,735 for a METHOD AND SYSTEM 
FOR ABSTRACTING NETWORK DEVICE DRIVERS, which is incorporated by 
reference herein in its entirety. 

15 Referring again to Fig. 3, the calling devices 88a and 88b in the illustrated 

embodiment may each execute bus drivers 83a-83b respectively. The bus drivers 83a 
and 83b wrap outgoing data into a bus-specific message, such as an ethemet or USB 
fi-ame for transmission over the network link 98a via the network interface cards 99a 
and 99b. Conversely, the bus drivers 83a and 83b may unwrap incoming messages to 

20 extract the underlying data or protocol layers. The bus drivers 83a and 83b are 
preferably implemented as network specific microports which are described in 
previously-referenced patent application. 
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The proxy host 82 of the illustrated embodiment may execute a networking 
program 81c and a bus driver 83c, which may have the same functions and possible 
embodiments as the networking programs 81a-81b and bus drivers 83a-83b. 
Additionally, the proxy host 82 may execute a call deflector program 84 to keep track 
5 of which virtual circuit, if any, has been assigned by the virtual circuit network 96 to 
one or more of the calling devices 88a-88b by maintaining entries in a call deflector 
table 86. Each entry associates a calling device with its assigned VC. The call 
deflector program 86 provides this information to a packet switcher program 94, 
which may also be executed by the proxy host 82. Based on the information provided 

10 by the call deflector program 84, the packet switcher program 94 links the input and 
output signals of the calling devices 88a and 88b with corresponding input and output 
signals of the network 96. Thus, once communication is established between a calling 
device and the network 96, virtual circuit cells traveling through the host 84 are 
passed to their appropriate destinations. 

15 To illustrate how communication occurs between devices over a virtual circuit 

network in accordance with the present invention, reference is made to Fig. 3 and the 
following example, in which concurrent virtual circuit calls are made from the calling 
devices 88a and 88b. It is assumed in this example that the calling device 88a makes 
the first virtual circuit call to the receiving device 93 a, followed by a second virtual 

20 circuit call from the calling device 88b to the receiving device 93b. It is also assumed 
that the virtual circuit interface device 92 is capable of sending, receiving and 
interpreting the device messages of the networking programs 81a-81c. In a remote 
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NDIS implementation, the interface device 92 would be known as "Remote NDIS 
compliant." 

The application program 85a on the calling device 88a sends a request for a 
virtual circuit connection to the networking program 81a. The request may include 
5 the destination address of the receiving device 93 a. The networking program 81a 
generates a virtual circuit "Setup" cell which may include the destination address of 
the receiving device 93a, wraps the cell into a device message, such as a remote NDIS 
OID, inserts the network address of the calling device 88a into the device message, 
and sends the device message to the bus driver 83a. The bus driver 83a wraps the 

10 device message into a bus-specific message, such as an Ethernet or USB frame, and 
sends the bus-specific message over the network link 98a via the NIC 99a to the NIC 
99c on the proxy host 82. 

At the proxy host 82, the bus driver 83c receives the bus-specific message 
from the NIC 99a, extracts the device message from the bus-specific message and 

15 sends the device message to the networking program 81c. The networking program 
81c reads the network address (of the calling device 88a) from the device message 
and extracts the virtual circuit cell from the device message. The networking program 
81c passes the virtual circuit cell to the packet switcher program 94 along with the 
network address of the originating device (calling device 88a). 

20 The packet switcher program 94 relays the virtual circuit cell and the 

originating network address to the call deflector program 84. In response to 
receiving this information, the call deflector program 84 examines the originating 
network address of the device message, generates a call reference value to uniquely 



identify the calling device 88a for the duration of this call, and makes an entry in the 
call deflector table 86 associating that call reference value with the network address of 
the calling device 88a. The use of call reference values in conjunction with virtual 
circuit protocols is well-known. The call deflector program 84 also inserts the 

5 generated call reference value into the header of the virtual circuit cell. 

The call deflector program 84 then passes the virtual circuit cell to the packet 
switcher program 94, which passes the virtual circuit cell to the networking program 
81c. The networking program 81c wraps the virtual circuit cell into a device 
message, such as a remote NDIS OID, and passes the device message to the bus 

10 driver 83c. The bus driver 83c wraps the device message into a bus-specific format, 
such a USB frame. The bus-specific message is transmitted out through the network 
link 98b to the virtual circuit interface device 92. The virtual circuit interface device 
92 transmits the virtual circuit cell to the network 96 over the network link 98c in the 
appropriate physical format, such as DSL. 

15 The virtual circuit cell is relayed through a series of switches, for example, the 

ATM switches 70-74 of the ATM network 120 of Fig. 2, to the receiving device 93a. 
The receiving device 93 a will respond with a virtual circuit Connect cell sent back 
through the network 96. At each switch along way, a virtual circuit will be assigned 
for communication between the receiving devices 93 a and 93b, thereby creating a 

20 data path 80a through the network 96. The virtual circuit "Connect" cell contains the 
virtual circuit number to be used in further communications by the requesting device 
(calling device 88a). 



The virtual circuit interface device 92 receives the virtual circuit "Connect" 
cell and wraps it into device message, such as a remote NDIS "create virtual circuit" 
OID and sends the device messages over the network link 98b wrapped into a bus- 
specific message, such as a USB frame. The bus-specific message travels through the 
5 bus driver 83c, in which the device message is extracted from the bus frame and 
passed to the networking program 81c. The networking program 81c unwraps the 
device message, extracts the virtual circuit "Connect" cell, and passes the virtual 
circuit "Connect" cell to the packet switcher program 94. 

The packet switcher program 94 then relays the "Connect" cell to the call deflector 
10 program 84. The call deflector program 84 reads the virtual circuit assignment and 
the call reference value from the "Connect" cell, correlates the call reference value 
with the network address of the calling device 88a, and based on that correlation, 
makes an entry in the table 86 that associates the network address of the calling 
device 88a with the assigned virtual circuit. The packet switcher program 94 sends 
15 the virtual circuit "Connect" cell to the networking program 81c which rewraps the 
cell into a device message, such as a remote NDIS OID, and sends the device message 
to the bus driver 83c. The bus driver 83c wraps the device message into a bus- 
specific message and sends it to the calling device 88a. 

When the bus-specific message reaches the calling device 88a, the bus driver 
20 83a unwraps it and extracts the device message. The bus driver 83a passes the device 
message to the networking program 81a, which unwraps the device message (e.g. by 
interpreting a remote NDIS OID), and extracts the virtual circuit "Connect" cell. The 
networking program 81a recognizes the virtual circuit "Connect" cell as being a 



response to the virtual circuit request, and stores the value of the assigned virtual 
circuit in a data structure for use during the subsequent virtual circuit call. The 
networking program 81a then notifies the application program 85a that the virtual 
circuit call may proceed. 
5 The application program 85a may then begin passing data to the networking 

program 81a for transmission to the receiving device 93 a during the virtual circuit 
call. The networking program 81a may create virtual circuit data cells containing the 
data received from the application program 85a and insert the correct virtual circuit 
number into the headers of the virtual circuit data cells, so that the cells will be 

10 appropriately transmitted across the network 96 to the receiving device 93a. 

From this point forward, the packet switcher program 84 will relay virtual 
circuit data cells originating from the calling device 88a to the virtual circuit network 
96. Furthermore, when the proxy host 82 receives incoming virtual circuit cells from 
the network 96, the call deflector program 84 will reference the call deflector table 86, 

15 correlate the network address of the calling device 88a with the virtual circuit of the 
incoming cells, and pass the virtual circuit cells received from the network 96 on that 
virtual circuit to the packet switcher program 94 for transmission to the calling device 
88a based on that correlation. The entry in the call deflector table 86 will persist until 
a "Release" message is generated by the calling device 88a or the network 96. The 

20 entry may then be deleted. 

While the communication between the calling device 88a and receiving device 
93a is still occurring, the calling device 88b may place a call to the receiving device 
93b by performing the steps described above as well. During the call setup, the call 
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deflector program 84 assigns a call reference value to the calling device 88b that is 
distinct from that assigned to the calling device 88a. The network 96 assigns a virtual 
circuit to that call as well, thereby creating a data path 80b over the network 96 to the 
receiving device 93b. The call deflector program 84 will create an entry it the call 

5 deflector table 86 that associates the assigned virtual circuit with the calling device 
88b. From that point on, the calling device 88a and the calling device 88b will each 
have their ovra virtual circuit over which to communicate with the network 96, and 
the packet switcher program 84 will cause the packet switcher program 94 to switch 
all of the data to and from the network 96 according to the entries in the call deflector 

10 table 86. Thus, from the point of view of the application programs 85a and 85b, the 
proxy host 82 appears as if it was the ATM interface device 92. This allows the 
application programs 85a and 85b to communicate with the network 96 as if they 
were coimected directly to it. 



15 may make virtual circuit calls in parallel with one or more of the calling devices 
linked to the proxy host 82. When an application program on the proxy host 82 
makes a virtual circuit call, an entry may be created in the call deflector table 86 in the 
same manner as described above with respect to the calling device 88a. 



20 communicating with a virtual circuit-based network has been provided. In view of 
the many possible embodiments to which the principles of this invention may be 
applied, it should be recognized that the embodiment described herein with respect to 



One or more application programs (not shown) executing on the proxy host 82 



It can be seen from the foregoing description that a novel method of 



the drawing figures is meant to be illustrative only and should not be taken as limiting 
the scope of invention. 

Those of skill in the art will recognize that the software components which are 
depicted in Figs. 1-3 as labeled boxes are meant to be exemplary only. Each box may 

5 represent a single program, or a group of programs. It will also be understood that 
although a software component may be illustrated as a single box, it may, in reality, 
be comprised of user-mode components as well as kemel-mode components. Also, 
the arrows drawn between the various software components (boxes) are not meant to 
be exclusive, as many of these components may communicate with components that 

10 are not shown. 

Furthermore, elements of the illustrated embodiment shown in software may 
be implemented in hardware and vice versa. The illustrated embodiment may also be 
modified in arrangement and detail without departing from the spirit of the invention. 
Therefore, the invention as described herein contemplates all such embodiments as 

15 may come within the scope of the following claims and equivalents thereof. 
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